Content

Spec-First Development 是一种开发方法论，强调在编写任何代码之前，必须先完成并敲定详细的设计规格（Spec）。其核心信念是：前期因审视和讨论假设所花费的时间，远低于因假设错误而在后期导致的返工与浪费。这种方法尤其反对“这个功能太简单，不需要设计”的直觉，认为越是看似简单的部分，隐藏错误假设的风险越大。典型的实践流程包括探索上下文、提出多个方案、撰写结构化文档，并经过团队或相关方的评审批准后，才将其拆解为具体的开发任务。

Acceptance

YoYo's Note

Question

• Spec-First Development 的适用范围是什么？在高度不确定或需要快速验证假设的探索性项目中（例如初创公司 MVP），这种方法是否仍然适用，还是会引入不必要的延迟？
• Spec-First 与 TDD 都强调“先设计后实现”，但 TDD 以测试用例为设计载体，而 Spec-First 以文档为设计载体。这两种方法在哲学基础和实践流程上有何本质区别？它们能否在项目中协同使用？
• 实施 Spec-First 时，如何避免设计文档陷入“过度设计”或“分析瘫痪”，从而违反 YAGNI 原则？是否存在一个判断设计“足够好”的启发式标准？
• 从历史演变看，Spec-First 方法论是如何从传统瀑布模型和敏捷开发的张力中发展出来的？它是否可视为对“前期设计”在敏捷语境下的重新定义，以平衡灵活性与可靠性？

See Also

TDD
YAGNI
Issue Quality
AI-Native 工程师
GTD

Reference

• 2026-03-20-superpowers-report
• Superpowers brainstorming skill

YoYo’s Note

Spec-First 是 Superpowers 的核心哲学之一：在写任何代码之前，必须先有被批准的设计文档。

核心论点：未经审视的假设造成的浪费 > 设计的时间成本。 越”简单”的项目越危险——因为你跳过了审视假设的机会。

实践流程：探索上下文 → 逐个提问 → 提出2-3方案 → 分节呈现设计 → 逐节获批 → 写设计文档 → subagent review → 用户审核 → 才开始拆任务。

关键反模式：「这个太简单不需要设计」← Superpowers 明确标记为最危险的想法。